メインコンテンツまでスキップ
バージョン: DAI 25.1

How Does Single Sign-On (SSO) Work in DAI?

Enabling single sign-on (SSO) allows DAI to use an external identity provider, such as Microsoft Entra ID, to manage and authenticate users. When SSO is enabled, DAI integrates the user management and authentication features of the identity provider with its embedded identity and access management (IAM) provider, Keycloak. This page provides a brief summary of how you can implement SSO with DAI.

Intended Audience: This topic is intended for DAI Administrators considering an SSO integration.

DAI supports integration with Microsoft Entra ID (formerly “Azure AD”) as an identity provider with the either the OpenID Connection (OIDC) or Security Assertion Markup Language (SAML) v2 protocols. Below are links to information about these options:

ノート

We recommend reading the rest of this page before you read the pages linked below for a better understanding of how the integration works before you begin to configure it.

ノート

When we talk about SSO integration with DAI, we're talking about its embedded access and identity provider: Keycloak.

How it works​

The following diagram summarizes how user data is maintained and shared between DAI and your identity provider.

DAI SSO Integration

Where are User and Asset Data Stored?​

When SSO is enabled for DAI, the user data are managed by the identity provider and the asset data and access control are managed by Keycloak as described below.

The Identity Provider Manages User Data​

Users and their credentials are created and managed exclusively by the identity provider (MS Entra ID). The assignment of roles to users (DAI Viewer, User, or Admin) is also managed exclusively by the identity provider. When users log into DAI for the first time, Keycloak creates a copy of the user based on the information it receives from the identity provider.

DAI Manages Model Access​

DAI (specifically, Keycloak) continues to own and manage its access groups and membership of those groups. DAI access groups are not stored in the identity provider and play no part in SSO, they are unrelated to groups in your identity provider. DAI uses groups to manage access control to DAI models.

ノート

Keycloak keeps a copy of the users and their role assignments and aligns it with data from the identity provider each time a user logs in.

Behavior​

When you enable SSO in DAI, your users experience the following authentication behavior:

  • If users try to access DAI when they are not yet logged in, they will be redirected to their identity provider to log in and then redirected back to DAI on success.

  • Similarly, logging out of DAI will log them out from their identity provider.

  • The first time a user logs into DAI with SSO enabled, DAI creates a user record in Keycloak and assigns that user a role. This is based on the data sent to DAI from the identity provider.

  • Each subsequent login will re-use this user account but keep it up-to-date with any changes from the identity provider.

  • DAI’s password and multi-factor authentication (MFA) features are disabled and hidden from users.

  • DAI’s user creation and editing features are disabled.

  • If you are a DAI administrator you can still access the Manage Access features of DAI but you will not be able to create or edit user accounts. You will only see users who have logged into DAI at least once.

Clarifications​

Below is a list of additional clarifications about how the DAI SSO integration works:

  • The DAI system administrator user is retained as a local user in Keycloak. This user will continue to be used for system upgrades and can be used when working with Eggplant Customer Support to investigate Keycloak-related issues. You cannot log into DAI with this user but you can access the Keycloak Admin Console.

  • Similarly, service accounts for DAI services, such as for service-to-service authorization, continue to be managed locally in Keycloak.

  • You can still remove users from the Manage Access page in DAI. However, this only deletes the user from Keycloak; it does not delete the user from the identity provider. You can use Delete User when you remove users from the identity provider and want to remove them from Keycloak. If you delete a user from Keycloak but not from the identity provider and that user later attempts to log into DAI, DAI simply treats the user as a new user who has never accessed the system before and creates a new user record in Keycloak.

  • You can still enable and disable users from within Keycloak, temporarily revoking their access to DAI.

  • DAI does not know about users until they log into DAI for the first time. Until that first login, you will not see the user in the Manage Access screens in DAI or be able to add the user to a group.

  • Credentials (e.g. passwords) are never shared with DAI (or Keycloak), your identity provider has sole responsibility for authentication and credential management.

Scope of SSO Support in DAI​

  • Keycloak does not currently support the System for Cross-domain Identity Management (SCIM) API. If a user is removed from Active Directory, that user will not be automatically removed from Keycloak.

  • While Keycloak can integrate with most identity providers (at least those supporting OIDC or SAML 2), DAI only supports integrations with Entra ID at this time.

に最終更新